The performance of select STAMP benchmarks with transactional cache hardware configurations

I have adapted STAMP benchmarks [1] for use with the MPARM simulator in order to evaluate the performance of transactional cache configurations. We are primarily interested in evaluating energy consumption in multi-core mobile devices. There are two main hardware configurations being evaluated: a simple transactional cache (“vanilla TM”), and a victim cache configuration. In the vanilla configuration all transactional data is stored in the transactional cache. In the victim cache configuration, transactional data is kept in local caches, but evicted transactional cache lines are stored in this victim cache. In general, this allows for larger read/write sets without overflowing, but increases the chance of aborts. There are several policy variations on these models that control the shutting down of the extra cache when not in use. However, The benchmarks I focused on spend almost all of their time executing transactions, so these models were not considered. I had previously adapted the kmeans benchmark, but concluded that the read/write set was too small and the transaction length too short to demonstrate the utility of a transactional cache. For this reason I next chose the two benchmarks in the STAMP suite that have medium-sized read/write sets, vacation and genome. In general, these benchmarks frequently overflow the simple transactional cache, and make consistent use of the victim cache.